ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group94b.txt/000036_icon-group-sender _Fri Sep 2 15:55:03 1994.msg

Internet Message Format | 1995-02-09 | 4KB

Received: by cheltenham.cs.arizona.edu; Fri, 2 Sep 1994 14:15:13 MST
To: [e-mail]
Date: 2 Sep 1994 15:55:03 -0400
From: [e-mail] (Nick Williams)
Message-Id: <347vun$[e-mail]>
Organization: Internet Online Services
Sender: [e-mail]
References: <[e-mail]>, <33vlde$[e-mail]>, <[e-mail]>
Subject: Re: Icon - still alive??
Errors-To: [e-mail]

In article <[e-mail]>,
Richard L. Goerwitz <[e-mail]> wrote:
>In article <33vlde$[e-mail]> [e-mail] (Nick Williams) writes:

>>I could deal with loadfunc really (as one of the examples in the IPL
>>demonstrates), but some things (setenv() comes to mind...) should be
>>standard. If the presence of more system dependent features makes Icon
>>programs non-portable, then they can be put in separate libraries along
>>with LARGE warnings...

>Sounds perfectly ghastly - using Icon for something it wasn't really
>intended.

What was Icon intended for then? Is it supposed to allow highly portable
programming by putting huge restrictions on what Icon programmers can
do? I bet not (why else would there be a preprocessor?, or &features for
that matter?). Frankly, Icon needs better access to system dependent
features (how dependent is setenv anyways? not much more than is getenv,
and that is already part of the standard set of functions), after all,
I don't always wish to write portable code because, after all, there are
some large differences between the various OS's that Icon runs under
(some irreconciliable, or which mean one OS is a much better choice for
a certain type of applications [e.g. Unix is better than DOS if you want
to write and run servers and still be able to use the machine for other
things]).

Forcing programmers to go hack the RTL code from which icont and iconc
are made or to write C function wrappers to system routines (plus Icon
wrappers as well), then relink the relevant libraries and executables
(or use loadfunc()) just to make them think twice before they use a
system dependent function is CRAZY! If the reason that is the way
things are has more to do with the fact that Icon is still being
developed, then fine, but it is something that ought to change.

Besides, Icon could turn out to be useful for more than just processing
text (why are graphics facilities would have been added otherwise?).

>           The most that I personally would like to see is a solution
>to the problem of calling C functions from Icon.  At least this would
>let each language do what it does without interference from the other.
>Trouble is that the memory management would, at times, conflict (e.g.
>if malloc is called).

So perhaps Icon should provide a replacement for malloc for C functions
linked or loaded in (a malloc() that allocates space that is not subject
to garbage collection!, and a free() too of course).

>Of course all of this is predicated on resources, and right now the
>Icon Project seems absorbed in graphics extensions (which is great).
>If improvements are to be made to Icon's C calling interface, this will
>need to come from outside, at least for now.

Indeed, and why are they putting in graphics extensions? because they
are *useful* to have (though _I_ don't use them often); the same would
apply to adding fork(), exec() and the like (system() is portable, but
limiting, not to mention dangerous).

>--
>
>   -Richard L. Goerwitz              [e-mail]
>   [e-mail]          rutgers!oddjob!ellis!goer

BTW, the whole world of programming/computing/administrating is ghastly ;-)

Nick